Wireless communication systems, such as the 3rd Generation (3G) of mobile telephone standards and technology, are well known. An example of such 3G standards and technology is the Universal Mobile Telecommunications System (UMTS™), developed by the 3rd Generation Partnership Project (3GPP™) (www.3gpp.org).
The 3rd and 4th generations of wireless communications, and particular systems such as LTE, have generally been developed to support macro-cell mobile phone communications. Here the ‘phone’ may be a smart phone, or another mobile or portable communication unit that is linked wirelessly to a network through which calls are connected. Henceforth all these devices will be referred to as mobile communication units. Calls may be data, video, or voice calls, or a combination of these. Such macro cells utilise high power base stations to communicate with wireless communication units within a relatively large geographical coverage area. The coverage area may be several square kilometers, or larger if it is not in a built-up area.
Typically, mobile communication units, or User Equipment as they are often referred to in 3G, communicate with a Core Network of the 3G wireless communication system. This communication is via a Radio Network Subsystem. A wireless communication system typically comprises a plurality of Radio Network Subsystems. Each Radio Network Subsystem comprises one or more cells, to which mobile communication units may attach, and thereby connect to the network. A base station may serve a cell with multiple antennae, each of which serves one sector of the cell.
A parameter of interest to operators of mobile communication networks is ‘quality of service information’. This is information that reveals how well the network is supporting users of the network. A high quality of service may be indicated by a very low rate of ‘dropped’ calls, or by very few mobiles experiencing low or highly variable signal strength.
In most known cellular networks, quality of service information is reported on a ‘per-cell’ or ‘per-sector basis’. This means that the network statistics obtained will only provide an indication of, for example, the average data rate or the average number of dropped calls in a given sector. These averages do not allow the network operator to narrow down the information, for example, to indicate if a particular portion of that sector is:
(i) Habitually causing calls to be dropped; or
(ii) Suffering from a poor data rate. A poor data rate may arise as a consequence of poor coverage in that particular area, or due to interference from a neighbouring cell.
A more detailed view of these issues is very useful to network operators. One prior art approach is thus to conduct ‘drive tests’, to assess coverage within a sector or cell. However, drive testing is expensive, and only provides data on what is happening at street level along the particular path taken during the test. The majority of phone and data calls are now made within buildings, and drive tests do not give any indication of the quality of service experience within a building. This is a major issue.
Geo-location is the identification of the real-world geographical location of, say, a mobile communication unit of a 3G system or the like. Geo-location of mobile communication units can be performed in several ways. These include providing a mobile communication unit with positioning equipment, such as GPS, or using network and mobile measurement data for nearby cells.
However, even if a user's terminal device has a GPS receiver built in, these devices are frequently disabled by users to save battery life. They are not included at all on many devices, e.g. low-cost handsets, data ‘dongles’ for laptops and machine-to-machine data communication terminals. The use of GPS data alone is therefore not sufficient to build an accurate picture of network service levels.
Some cellular systems are mandated to provide user location information when an emergency (‘911’) call is made. Again these calls are not sufficiently frequent to build up a good picture of the quality of service experienced throughout a network at all times of the day and night, and in all seasons of the year. In addition, the network equipment architecture required in these ‘E911 Geolocation’ systems is complex, since every base-station in the network needs to be fitted with an additional piece of electronics in order to locate the user to a suitable (mandated) degree of accuracy, which is typically 100 m. To use this type of architecture for service quality assessments throughout a network would be prohibitively expensive.
The network statistics referred to above, which only provide the average data rate or the average number of dropped calls in a given sector, are insufficient for some tasks faced by network operators. For example, if a particular mobile user complains that he is often subject to poor service, the data that is available may not help. Likewise, some individual faults in the network, such as wrongly directed antennae, may not be revealed by the ‘average’ data.
To try and improve the information available on service levels, some operators have attempted to compile more comprehensive data for a limited time on what exactly is happening in one sector or one cell of a network. There are two reasons why this is rarely done, as follows:
(i) A vast amount of data is created, even for a short time period, such as a few hours. Storing this data in a retrievable form is very expensive.
(ii) Once data concerning calls made in a sector or cell of a network has been recorded for a period of a few hours, it then requires specialist post-processing. Without this, it is very difficult to access individual records within an acceptable time. After post-processing, any information that can be gleaned about a user, or part of the network, is then often only available several hours after the end of the data capture. This may be several days after a user has made a complaint. Even such information is only of limited value.
FIG. 1 shows one prior art approach, in the form of a flow chart.
The approach shown in FIG. 1 is usual in the ‘batch processing’ technique used by known systems. Method 100 of FIG. 1 gathers all of the information for a time period after a problem arose in a network sector. Step 110 involves deciding where to place a probe. Step 120 involves operating the probe for long enough to obtain meaningful data. Step 130 involves specialist off-line processing of the information. Step 140 involves a user deciding what can be understood, from the processed data. Step 140 may take many different forms, depending on the reason why the probe was added to the network.
With the process of FIG. 1, the data is essentially obtained manually by the operator of the network, and processed off-line. This typically results in a delay of many hours, between the event of interest taking place and the resulting diagnostic information being available.
The fact that the process of FIG. 1 is ‘retroactive’ may also be a problem. It will only assist in identifying a fault:
(i) If it is a network fault that is still detectable, rather than one that only occurs intermittently.
(ii) If the user happens to be active during the few hours when the data is captured, in cases where the fault is due to a faulty handset.
In summary, the prior art relies on average statistics for much quality of service analysis. Where data is captured, it is often only of value if a fault happens to re-occur during the period of capture. Skilled analysis is required to process the captured data.